@slnode test please

@bajtos @0candy PTAL

We can either land this or #2767

+1 for adding a new API that's consistent with strong-remoting API.

Could you please add a unit-test? At least copy & modify the existing test here that verifies remoteMethodDisabled event. It would be nice to have a test to verify that disabled methods are not accessible via REST too, but I am ok to land this PR even without that.

As for the existing Model.disableRemoteMethod method, I am proposing to

• rework it to keep the same public API for backwards compatibility
• call the new disableRemoteMethodByName under the hood
• print a loopback-specific deprecation warning

See how SharedClass.prototype.disableMethod is implemented in strong-remoting (link) and use the same approach here.

@bajtos changes have been made as per your request

All three failed Windows builds are caused by Cannot start PhantomJS, I think it's ok to ignore this error.

The loopback-component-explorer failure is unrelated, see strongloop/loopback-component-explorer#178

Landed, thank you @richardpringle. Could you please back-port the new API to 2.x (without the deprecation notice)?

@richardpringle we have a unit-test in loopback-component-explorer that's triggering a deprecation warning, could you PTAL?

strong-remoting deprecated SharedClass.prototype.disableMethod is deprecated. Use SharedClass.prototype.disableMethodByName instead. node_modules/loopback/lib/model.js:439:22
    ✓ updates swagger object when a remote method is disabled

Because the same version of loopback-component-explorer is supporting both LB 2.x and LB 3.x, it will be best to have the new API backported to 2.x, so that the tests in explorer can rely on this new API.

@bajtos:

Could you please back-port

backport -> #2781

LB-component-explorer PR -> strongloop/loopback-component-explorer#181